Mostly-Copying Collection: A Viable Alternative to Conservative Mark-Sweep

Many high-level language compilers generate C code and then invoke a C compiler to do code generation, register allocation, stack management, and low-level optimization. To date, most of these compilers link the resulting code against a conservative mark-sweep garbage collector in order to reclaim unused memory. We introduce a new collector, MCC, based on mostly-copying collection, and characterize the conditions that favor such a collector over a mark-sweep collector. In particular we demonstrate that mostly-copying collection outperforms conservative mark-sweep under the same conditions that accurate copying collection outperforms accurate mark-sweep: Speci cally, MCC meets or exceeds the performance of a mature mark-sweep collector when allocation rates are high, and physical memory is large relative to the live data. 1 High Level Overview Languages such as C [1] and C++ [27] are GC-unfriendly because they allow programs to violate the key premise of tracing garbage collection|that all live objects are reachable by a sequence of pointer traversals from the root set. For example, a program might violate this premise by using pointer arithmetic or casting. Consequently, compilers for GC-unfriendly languages do not support garbage collection and do not provide the information necessary to distinguish pointers from other data. This makes accurate garbage collection infeasible. Conservative tracing garbage collection is a practical memory management approach for GC-unfriendly languages [14, 11, 13, 12, 16, 8, 7, 9, 10]. This approach is practical because only minor modi cations are necessary to add memory management to most programs; and no special compiler support is required. This material is based on work supported in part by the AFOSR grant F4962097-1-0013 and ARPA/RADC grant F30602-96-1-0317. Any opinions, ndings, and conclusions or recommendations expressed in this publication are those of the author and do not re ect the views of these agencies. y Supported by a National Science Foundation Graduate Fellowship. z Instead, a conservative garbage collector relies on the programmer, rather than the compiler, to ensure that the program does not violate the invariants it requires. For a typical collector these invariants might include not mangling pointers, always retaining a pointer to the beginning of an object that is in use, and only using the collector's allocation routines. Indeed, conservative collectors are so practical that a variety of compilers for GC-friendly languages, including TIL/C [29, 20, 28, 30], Toba [22], Harissa [21], Bigloo [24] and Vortex [15], have chosen to use a conservative collector and to compile to C rather than use an accurate collector and generate assembly code. The implementors of these systems have decided that the portability of C, and the optimizations a orded by pre-existing C compilers outweigh the bene ts of accurate collection. Given the many compilers using conservative collection it is remarkable that all of the above compilers link the resulting code against the same conservative collector: The Boehm-Weiser collector (BWC) [14]. BWC is based on a marksweep algorithm, and was designed to be used in systems where type information is generally unavailable. Compared to copying collectors, mark-sweep algorithms tend to require less memory, but have greater allocation costs, the potential for greater fragmentation, and a running time that is proportional to the size of the heap. In this paper, we present a new collector based on an improved version of the mostly-copying collection algorithm of Bartlett [7, 8, 10] as an alternative to BWC. Our collector (MCC), in contrast to BWC, is targeted at code generated by compilers, and thus expects type information to be available for most, but not all objects. Because MCC is mostly a copying collector it has many of the same performance characteristics as an accurate copying collector: compaction, fast allocation, and running time proportional to the live data [19]. Brie y this is how MCC achieves these characteristics. To achieve fast allocation, MCC organizes the heap into pages . The client rst allocates a page from the collector, and then lls the page with objects in a contiguous fashion. Thus, allocation has the same amortized cost as for an accurate copying collector. To achieve compaction and running time proportional to the live data, MCC, when invoked, attempts to perform a standard copying collection. However, when type information is unavailable for a word that appears to be a reference, the collector marks the referenced object and pins the page containing the object. Objects on pinned pages remain in place, but all other objects are copied and compacted onto free pages. After traversal, the collector reclaims all unused pages. To validate the claim that mostly-copying collection is a viable alternative to conservative mark-sweep we compared the performance of eight ML benchmarks using both MCC and BWC for a modi ed version of the TIL compiler that generates C code, TIL/C. The results show that the characteristics of each programdetermine which collector performs best, and that the tradeo s involved in choosing MCC over BWC are the same as those involved in choosing an accurate copying collector over an accurate mark-sweep collector. In particular, MCC z See [13] for a discussion of what compiler support is required.